1. Field of the Invention
The present invention relates generally to an operation method of a mobile application model. More particularly, the present invention relates to an operation method of a mobile application model that separates mobile applications into individual views and operates the individual views with independent processes.
2. Description of the Related Art
Typical application models include all views that are provided by an application in a single process. The application includes a set or thread of functions for respective constituent views.
A shared library-type application model has an application configuration that is equivalent to an application model that includes multiple views in a single process. However, the shared library-type application model loads shared codes commonly used among its applications in order to speed up boot times of the applications.
In an application model that includes an application having a single thread, all functions of the application are included in the single thread. In this application model, a plurality of applications may exist in a single process, and a memory may be shared by the applications in the single process.
In a message-based application model, all applications in the system operate as a single thread, and each application is executed by invoking a relevant function through message delivery.
The message-based application model is most widely used to develop mobile software. This is due to the fact that the message-based application model provides fast reactivity despite its low CPU performance, which is caused by hardware and software characteristics of existing mobile terminals.
FIG. 1 is a diagram illustrating an operation procedure of a message-based application model.
In a message-based application model conventionally used to develop mobile software, all applications included in the system as well as the application in use are running because the applications are included in one process.
Referring to FIG. 1, if message application execution (or message list application) is selected in an idle state “idle” in step 100, a “message” view (new message view or message-write view) is displayed on a display. If a contact list application is selected in step 101 after message content is written in the “message” view, a “contact” view (contact list view) is displayed on the display. When a recipient is selected in the “contact” view and an OK is input in step 102, the “message” view, on which the message content is written, is displayed. Thereafter, if a message sending application is selected in step 103, the message is sent.
While the above operation is being executed, a code for the idle state, a code for the message writing, a code for the contact list, and codes for other applications aside from the message application are stored and preserved in a memory.
Therefore, when the message application is being executed through the message-based application model, codes for executing other views aside from the view that is currently displayed are also continuously loaded in the memory, causing a waste of memory.
Further, when the memory is shared among the many applications, the system may crash due to an error of one application, which may result in the propagation of serious and latent bugs.
Additionally, since applications are executed by function invocation through message delivery, codes for managing and scheduling all applications are created in an application stage, and not in a system kernel stage.